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(57) Embodiments of the invention include a nnetlnod 
and an architecture for specifying network resources 
based on applications requirements; Applications re- 
spui^ces are defined with the Asynchronous. Transfer 
Mode (ATM) Quality of Service (QoS) parameter and the 



network resources are allocated based on Resource 
reservation Protocol (RS VP) flow specifications. An 
end user or automated. application can define! the re- 
sources desired for their application using a policy nnap- 
ping database that maps the ATM QoS parameters to 
the RSyP flow specif iciat ion. 
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Description 
Technical Field 

This invention relates to data cGmmunications and 
computer networking. 

Background of the Invention 

The field of data communications is primarily con- 
cerned with how devices talk to each other. As in the 
case of human beings, for devices to speak to each oth- 
er they need to use and underetand the same language. 
These Icinguages are called communtcaiions protocols. 
The protocols are agreed upon standards that are nor- 
mally based on layered models which enable different 
vehdor equipment to communicate (inter-network). A 
complete exposition of layered model protocols is given 
in Andrew S: Tannisnbaum, Computer Networks. 2nd 
Edition. F^rentice Hall. 1989. 

One pi the new emerg ing protocols is the Asynch rp- 
nous transfer Mode (ATM) protocol. ATM can t)e incor- 
poriated ifito one of the most prevalent computer prblo- 
cdls, the Transmission Control Protocot/lnternet Proto- 
col (TCP/IP). FIG. 1 displays a conceptual diagram of 
ant IP over ATM Host Protocol Stack. A physical lawyer 
1Q pt an ATM network consists of a regenerator level 15 
which regenerates weakened signals, a digitaljsection 
level 20 which disassembles and assembles a continu- 
ous byte siream, and a transmission path level 25 that 
assembles and disassembles the paybad of the. sys- 
terh: Sitting above the physical layer 10 is the ATM layer 
30. The ATM layer is composed of a virtual path level 
35 and a virtual channel level 40. The virtual path level 
35 is composed of a bundle of virtual channels that have 
the same endpoint. The virtual channel level 40 is con- 
cerned with issues like the Quality of Service (CtoS), the 
svyitched and semi-permanent virtual-channel connec- 
tions, cell sequence integrity, and traffic parameter ne- 
gotiation and usage monitoring. The QoS parameter al- 
lows ATM to provide network resources based on the: 
different types of applications being used. Forefxample. 
an application may send out short bursts of information 
- therefore the application does not require a long con- 
nection (e.g.. logging onto a remote computer). On the: 
other hand some applications require a large amount of 
information and not necessarily reliable data.transler (e. 
g. video conferencing). Utilizing the GoS parameter in 
an ATM network, a file transfer can ba handled differ- 
ently from a video conference. An AAL5 layer 50 is the 
segmentation and reassembly sublayer and is respon- 
sible for packaging information into cells for transmis- 
sion and unpacking the information at the other end. An 
LLC/SNAP layer 60 provides a mechanism for encap- 
sulating other protocols (e.g., IP. Novell IPX) over ATM 
AAL5. An IP layer (70) is the network layer of the IP pro- 
tocol suite, and provides a common packet format and 
addressing scheme capable of transporting data over 



multiple subnetwork technologies (e:g;, Ethernet, ATM). 
A TCP layer (80) and UDP (User Datagram Protocol) 
layer (80) provide different types of transport services 
over IP. Applications (90) residing within an end^system 

5 may access TCP and UDP services via an applications 
API (Application Programming Interface); 

Communication between devices in a network is 
performed digitally'. The information to be corpmunicat- 
ed is usually represented as O's or 1*s, The information 

10 or data to be communicated (O's and 1 's) is usually 
grouped and separated into units called packets. The 
layered modeled protocols discussed above are imple- 
mented In these f^ckets by deifining meanirig to bits In 
the packets, defining diff erent types of packets and de- 

ts fining the sequencing of the different types of packets. 
Once data or information has been segmented into 
packets, the packets . are sent into the network where 
they may take the same path or separate paths- The 
packets are ultiinatiBly recbmbined at the end device. In 

20 ATM, a: corttmuhicatioris path between two devices is 
established through a virtual circuit. The circuit is called 
a virtual circuit because the path may be established 
and then removed, and resources atong the path may 
be shared by multiple virtual circuits. When the packets 
are sent through rietwork switches that established vir- 
tual circuits through an automated call-setup procedure, 
the paths are called switched virtual circuits (SVCs). 

!h jain IP packet rletwork^ a packet is sent from a 
transmittiiig device onto the local network and then 

30 transmitted to a device called a, router. The router for- 
wards the packet intpthe network. Conventional models 
for IP over ATM have described a method of communi- 
cating directly between two end devices (possibly on dif- 
ferent subnetworks) once a path between the two de- 

35 vices has been established. An emerging protocol 
called the Next Hop Resolution Protocol (NHRP) and 
NHRP servetrs (NHSs).may be employed to map IP ad- 
dresses from endpoints on d'rfferent IP networks to their 
corresponding ATM addresses. Once the destination 

40 ATM address is acquired, a direct ATM path between 
the source and destination may be set up. When the 
source and destination are members of different subnet- 
works, such as an ATM. SVG is referred to as a cut^ 
through orshort cut SVC. Using this approach, all of the 

4S packets take the same path (virtual circuit) between the 
two end devices. However, in an alternative model, the 
communications connection between two end devices 
may be established so that all packets are processed 
through. a router. When packets are processed through 

^0 a router the packets may not all take the same path. 
Processing packets through a router is advantageous 
when the applications being pe.iorhned are small appli- 
cations (small in time, small in bandwidth). However, 
processing becomes difficult when the applications 

55 have larger requirements (larger time requirements, 
larger bandwidth requirements). Therelore, when the 
applications have larger requirements, it is generally ad- 
vantageous to use a switched virtual circuit between two 
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communicating end devices. 

When ATM is used in the TCP/iP environment one 
of the key issues is SVC connection management. At 
one end pf the spectrum a SVC could be established 
between all communicating entities. At the other end pf s 
the spectrum all communicating entities could be forced 
to go through a router. Grven the diversity of applications 
each of these solutions would be lackang. Therefore, it 
would be advantageous to allow SVC management to 
be controlled by the requirements of the application. io 
specifically the QoS requirement of the application. 

In conventional TCP/IP applications, the decision of 
whether touse an SVC or a router is based on the trans- 
mitting and destination IP.address. Transport protocols 
such as TCP and UDP use pprt numbers to identify an 
application associated with an IP address. Some port 
numbers (1-255) are well known and represent services 
such as hcst functions, filelransfer, and network news. 
Other port nunribers (1024-65535) are not well known 
and therefore maybe used to identify QoS requirements 
jo a commuri icatipn s session. 

An alternative mechanism for communicating the 
QoS requirehients of ah applicatipn is through a current- 
ly evolving Resource reSerVation Protocol (RSVP). 
RSVP enables the resen/atioh of resources and QoS 
negotiations in an IP network. RSVP operates within the 
context of .the IP protocol and therefore does not take 
into account the particular subnetwork technology (e.g. . 
ATM) that IP rnay be operating over. Hence the resource 
reservation and QoS negotiations occur between com- 
municating endrsysterns and network routers. In 1he 
RSVP protocol methodology a source would send a 
path imessage to a destination address to identify a com- 
rnunicatiors route. The destination would request the 
resen/ation of resources for a ^low" along the route. 
Lastly, if the destinations reservation request is accept- 
edi the flow receives the requested network resources 
and QoS from the path. 

The RSVP methodology is supported by several 
component parts of the RSVP protocol. The first com- 
ponent part is a flow specification which describes the 
characteristics of the packet stream sent by the source 
(e.g., shortpackets of intermittent frequency for terminal 
communications^ longer packets that are generated at 
more regular intervals fcr video teleconferencing). The 
flow specif cation specifies the desired QoS and is used 
to set the packet scheduler parameters. Next, a routing 
protocol provides communication paths. A setup proto- 
col enables the creation and maintenance of the re- 
sources reserved. An admission control algorithm main- 
tains the nBtwork load at a proper level by rejecting re- 
source requests that would cause the level to be ex- 
ceeded. Lastly, a packet scheduler is placed in the rout- 
ers in the path between the source and destination to 
assure the right QoS. 

FIG. 2 displays a flow model of the RSVP model as 
it is currently implemented over an IP network. In the 
current implementation ol RSVR packets are classified 



based on their "sesston" and ^Iterspec* parameters 
(based on among other things, source and destination 
addresses), and service by the IP protbcol is based on 
the llGW specification (referred to as a "flow* for short). 
The flow model of FIG. 2 shows packet processing with- 
in a router. A classifier 110 separates communicating 
packets based on their 'session* and 'filterspec* param- 
eters as shown by 1 20. The packets are then channeled 
into a packet scheduler 1 30 for processing by an output 
driver 140. which outputs the data at 150, the interface 
leading to the "next-hop" router in the path to the desti- 
nation (or the destination Itself in the pase when the 
next-hop is the destination). 



The invention is as defined by the claims. Embodi- 
ments of the invention include a method and architec- 
ture for implementing Resource reservation Protocol 
(RSVP) over Internet Protocol/Asynchronous Transfer 
Mode (IP/ATM). In the inventive architecture, the re- 
sources necessary for a communications pathway be- 
tween two devices are defined by applications resource 
requirements. The applicaticns requirements are 
mapped into RSVP parametersvia an RSVP and IP car 
pable Application Programming Interface (API), resi- 
dent in the host computer; When ATM is used in a net- 
work, a straightforwar'd approach is to translate RSVP 
flow specification parameters to corresponding ATM 
QoS parameters (Note that the mapping of RSVP pa- 
rameters to ATM parametisrs do not correspond exact- 
ly). Thus, if X represents the set of RSVP parameters, 
and /isthe set of ATM QoS parameters, then Y- F(X), 
v\^ere F is a: function that maps X onto Y: 

Embodiments of the invention augment the map- 
ping of RSVP to ATM by utilizing a database (d) as an 
interface between the RSVP parameters and the ATM 
parameters. The database (d) contains user end point 
(also referred to as a customer) data, used to charac- 
terize the network requirements of the customers. 
Therefore the mapping of RSVP parameters to ATM 
QoS pararheters now takes the form Y = F (X d), where 
X, Vand Fhave the same meaning as above, and d is 
a policy mapping database (PMD); This database is 
consulted whenever a mapping frpm Xto /is to be per- 
formed. The use of the database permits decisions and 
choices to be made that are not possible when a straight 
forward mapping from Xto Y is employed. 

Advantageously, the policy mapping database 
(PMD) gives a ussr the ability to. e.g.. enable a "short- 
cut" SVC with QdS mapping or without QoS mapping, 
disable a "short-cuf SVG establishment and support 
hop-by-hop QoS mapping. The database enables the 
user to define whether the Next Hop Resolution Protocol 
(NHRP) is invoked or not, whether a SVC backup should 
be established, whether a time of-day override should 
be implemented, or v^ether an alternate ATM path 
shojld be used when the primary ATM path fails. 
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Also, the mapping from X to Y is dependent, e.g.. 
on customers' subscriptions to different^levels of secu- 
rity, priority and performancei time of day information, 
and Information about the network state. In summary, 
RSVP flow specifications are mapped to ATM switched 
virtual circuits with specified QoS using a PMD. As a 
result of mapping the flow specifications of RSVP to the 
QbS requirements of ATM, the inventive method and ar- 
chitecture enable the implementation of RSVP over IP 
over ATM. 

Brief Description of the Drawings 

the objects, advantages and novel features of the 
Invention will be more fully apparent from the followng 
detailed description when read in connection with the 
accpmpanyihg drawings wherein: 

FIG, 1 displays the TCP/IP protocol stack over the 
Asynchronous Transfer Mode protocol stack; 
FI0. 2displ.ays RSVP operation ovBr anon-QoS ca- 
pable sub-network; 

FIG. 3 displays a fiow rhodel of the RSVP protocol 
oyer IP over ATM with a policy mappirig database 
(PMD) used to manage the protocol translation; 
FIG. 4a describes^a detailed cbmrnuriicalioh be- 
tween a source (S), a,destinatipn (D), a PMD, . and 
an address resolution/next hop server (NHS), ac- 
cording to the methodology of an embodiment of the 
invention, wherathe source queries the NHS; 
FIG. 4b describes a detailed communication be- 
tween a source (S), a destination (D), a PMD, and 
an address resolution/next hop server (tslHS), ac- 
cording to the methodology of an embodiment of the 
inyenttpn. where the PMD queries the NHS; 
FIG. 4c describes a detailed: communication be^ 
tween a source (S), a destination (D), a PMD, and 
an address resolution/next hop server (NHS), ac- 
cording to the methodology of an embodiment of ihe 
invention, where thePMDqueriesthe NHS and sets 
up the connection betweien the source (S) and des- 
tination (D) using third party call setup rhechanishns; 
and 

FIG. 4d shows a scenario according to an embodi- 
ment of the invention where the deslinatton (D) sta- 
tion queries a PMD and sets up an SVC; 
FIG. 4e details a scenario according to an embod- 
iment of the invention where the destination (D) 
queries the PMD and No Cut-Through SVC results; 
and 

FIG. 5 details the contents of the PMD according to 
an enrtbodiment of the invention. 

Detailed Pescrlpllon of the Invention 

The present invention is directed to a method and 
architecture for allocating network resources (e.g.. 
bandwidth, priority) based on the type of application that 



is being used at the comrnunicating endpoints. The 
Asynchronous Transfer Mode (ATM) Architecture and 
the Resource reservation Protocol (RSVP) protocol in 
combination have tfie necessary comppnents to enable 
the allocatk>n of network resources based on the appli- 
cation. In the ATM protocol traffic descriptors and the 
Quality of Service (QoS) feature can be used to estab- 
lish d'rfferent network requirements based on the appli- 
cation. For example!, since a telnet session uses smaller 
infrequent packets which could be transferred through 
a router, a set of traffic descriptdrsahd Quality of Service 
parameters th^t defineis this Idnd of connection could be 
e^tabitshed. However, if a video cpnfer^nce is estab^ 
Itshed. large, delay sensitive packets would be frequent- 
ly generated. Therefore, a dedicatied switched virtual cir- 
cuit with low delay sensitive characteristics would be 
more efficient to carry oh a video cbrif eriehcihg sesskxi. 

The RSVP protocol is implenriented with compo- 
nents that complete the requlrernehts necessary to cre- 
ate bandwidth -albcations based on QqS, The RSVP 
protocol inctudes.classifiers.v^^ 
and flow specifications which define and detail relevant 
characteristics of (he packets. Lastly, the RSVP param- 
eters and flow specifications, are; mapped to ATM 
switched virtual brcuits (SVCs) with corresponding traf- 
fic descrifjtors.andQbS pairarneters using a policy map- 
ping database (PMD). The PMD cprrelaties the RSVP 
flow specifications tp the ATM QoS parameters of SVCs. 

FIG. 3 displays a llow model of an RSVP protocol 
according to an ernbodiment of the invention. The flow 
model of RSVP over ATM correlates the flow spec ifi 
tiohs and Q6S Switched virtual circuits, to establish ATM 
SVCs. In FIG. 3; a classifier 210 classifies packets 
based on their se^ion and filterspec parameters. Each 
classification of packets has ah associated flow specifi- 
cation 220. The flow specificalions 220 are fed into a 
policy mapping database (PMD) 230. PMD 230 maps 
the packets based on the flow specification 220. PMD 
230 enables the mapping between the RSVP flow spec- 
ification parameters 220 and the ATM QoS parameters 
240. The majDping of flow specifications 220 to ATM 
SVCs is based on the resources required by the appli- 
cation (e.g. . best effort t raff icmay be mapped to a routeifj 
and video conferencing would be mapped to separate 
SVG with appropriate traffic descriptors and QoS pa- 
rameters). A user interface to the policy mapping data- 
base (PMD) can be established to allow users to man- 
age the mapping for their own traffic. 

FIGs. 4a-e give an end-to-end flow diagram of the 
sequence of etejps for the unicast (transnnission of a 
packetfrom one end point to another eridpoiht) case. In 
the disclosed methodology, the customer initially enters 
the varbus service options (0) in PMD 230, together with 
the list of IP end-points to which the options apply (Note 
that a single customer rrtay have rnultiple entries in the 
database, i.e.. one subnet of the customer end-points 
may have diffiarent options than another subnet). When 
a source (S) wishes to communicate with a destination 
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(D). source (S) sends a path message (1) directed to- 
wards destination (D) via its next-hop router 110. The 
path message (1) is thehfoirwarded hdp-fay-hop towards 
destination (D) via steps (2). (3), and (4). After destina- 
tion (D) receives the path message, it returns a reser- s 
vation request back to source (S) hop-by-hop in the re- 
verse direction using the route taken by the path mes- 
sage in steps (5), (6). (7) and (8). Ihe route information 
necessary for these steps is maintained in routers' 110, 
120 and 130 as PATH state Information. When source 
(S) receives the;reservation, it sends aquery (9) to PMD 
230. The PMD does not have to be physical^ co-located 
with source (S), The PMD is reachable via its ATM ad- 
dress, which is known to source (S). The query (9) con- 
tains all the information from the original received res- 
ervation messages. Query (9) is processed by PMD 230 
and a response (10) contathihg the required ATM traffic 
descriptors and QoS parameters, and infbrmation per- 
taining to the various PMD specified dptiohs is returned 
to source (S). The details of the query arwi response 
messages from source (S) to PMD 230 are specified be- 
low. Once source (S) has the results ol the response 
(10), and assuming the service options, network state, 
etc., pemnit cut-through, source (S) sends an NHRP 
query (11) to its default NHS 140 and receives a re- 
sponse (12) containing the ATM address of destination 
(D). Source (S) then siets-up an ATIV! SVC (13) directly 
to destination (D) using the ATM QoS information from 
response (10). 

The methodology and architeclure disclosed in FIG. 
4a can be modified to improve performance and conduct 
processing on behalf of end-systemclfents. In the archi- 
tecture of FIG; 4b, operation is identical to that of FIG. 
4a up to and including query rinessage (9). After receiv- 
ing query (9), the PMD initiates an NHRP request (10) 
to the NHS on behalf of the source. The NHRP request 

(10) is signaled by an NHRP lookup option in the PMD 
query message (9), which also contains the IP address 
of destination (D). When PMD 230 receives NHRP reply 

(11) for the NHS, it responds with a response (12) to 
source (S), The response now additionally contains Ihe 
ATM address corresponding to the IPaddreiss of desti- 
nation (D). The source (S) is now able to setup a call 
(13) directly to destination (D), without having to go 
through the step of consulting an NHRP server, because 
the NHRP server was accessed by or may be located 
in PMD 230. 

A further efficiency is possible when an NHRP 
lookup option is enabled. As shown in FIG. 4c, a 3rd 
party ATM call setup is initialed by PMD 230 via proxy 
signaling (i.e., when a parly other than the communicat- 
ing endpoints signals the endpoints for communication 
established). Proxy signaling is signaled by the source 
(S) to PMD 230 by a 3rd party/proxy signaling call setup 
option in the PMD query message (S) (it is assumed that 
the PMD has been provisioned to carry-out proxy sign- 
aling on behalf of both source (S) and destinatran (D); 
this requires that a "signaling" Virtual Circuit be set-up 



between PMD 230 and the communicating endpoints). 
In FIG. 4c, operation is fclentical to that of FIG. 4b, up to 
and including reply (11). Afterwardi PMD 230 initiates a 
3rd party ATM cat! setup request (12) via proxy signialing 
to the ATM network 300 on behalf otboth source (S) and 
destination (D). An ATM connection (13) is tlien setup 
between source (S) arid destination (D). When the con- 
nection setup is complete, a proxy signaling confirma- 
tic«i message (14) is received from ATM Network 300. 
PMD 230 then issues a proxy signaling confirmation 
nfiessages (1S) tosource (S) and (16) to destination (D). 
The confirmation messages may include Virtual Path/ 
Virtual Channel Identifier (VPIA^GI), addressing infor- 
roation, QoS, and other information received in mes- 
sage (14). The ccnfirmatibn (15) to source (S) may be 
piggy backed in the PMD response (17), so that a sep^ 
arate message need not be sent: Source (S) is now able 
to send to destinatioh (D) using the VPIA/C I information 
received in messiage (15) without either having to do an 
IP to ATM address translation, or an ATM call setup re- 
quest 

Af urther nriodification to the methodology disclosed 
above results in a significant improvement to the overall 
performance of the system. The improvement results 
from not reserving resources iri the intennnediate routers 
(11 6, 120. 130) between source (S) and destination (D) 
in case axutHhrough is penrhitted and an SVCJs estab- 
lished between source (S) and destination (D). To. ex- 
plain this point, observe that in theabove scenarios, the' 
RSVP resen/ation request-message that was returned 
back from destination (D) to source (S) results in the re- 
serving of resources at each router (110. 120. 130) 
along the path from destinatton (D)to source (3). Incase 
the end result is to permit cut-through and establish an 
ATM SVC (13) between source (S) and destination (D). 
tvyp issues result. First a mechanism should be used to 
free any reserved resburceis along the path defined 
through routers 120, 130 and 140. This , sirhply can be 
achieved either through a time-out mechanism or by let- 
ting source (S) send an RSVF Reservation teardown 
message. The second more significant issue Is that new 
reservations that actually require resources in these in- 
termediate routers (e.g.; because cut-through is not per- 
mitted for these reservations) may be blocked because 
of lack of resources in routers 110, 120 and 130, or as- 
sociated links in the network. This issue is addressed 
by allowing destination (D) to query PMD 230. If cut- 
through is permitted, then destihalkan (D) establishes 
the SVC to source (S) and sends Its RSVP Reservation 
Request message to source (S) over the SVC. In other 
words, no RSVP Reservation Request message is sent 
back hop-by-hop in the reverse direction along the route 
taken by the RSVP Path message, and no resources 
are reserved inthe intemiediate routers. Nptethat clear- 
ing Ihe path state information in the intermediate routers 
(that was created when processing the Path message) 
is still required. This is not considered a problem be- 
cause no considerable amount of memory is required to 
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store the path state information. 

There are still two issues to resolve at source (S). 
when using destination (D) to set-up the SVG. The first 
issue is how to associate the received RSVP Reserva- 
tion Request message to the Path message that was s 
previously sent. Obsen/e that if destination (D) has que- 
ried PIVID 230 and cut-through is permitted, the RSVP 
Reservation Request message is recerved by source 
(S) over a virtual circuit which is different from the virtual 
circuit over which the R3VP Path message was sent. io 
The RSVP protocol associates RSVP PATH and RSVP 
Reservation messages by using a message ID field in 
these messages, Wq additionally require the use of 
unique message ID over a single interface, the same 
message |D should not be used over separate virtual is 
circuits supported on the interface to identify different 
reservatioiis. 

The second issue arises when ^Urce (S) receives 
an RSVP Reservation Request miessage over the same 
virtual circuit that was used to send the RSVP Path mes- 20 
sage. Theproblerri source (S) faces is hbwto distinguish 
between the following two cases. The first: case is that; 
a query to the PMD was performed by destination (D) 
and cut-through was not permitted. In this case, a sec- 
ond query to the PMD by source (S) must be avoided. 2$ 
The second case is that a query;to the PMD was not 
performed by destination (D): arid a query to the PMD' 
by source (S) must be performed. We solve this p rob I iem 
by definingan end-^to-end user signaling mechanism be- 
tween source (S) and destination (D). The method dis- 30 
closed in the present invention advocates the use of an 
RSVP Object vwth an unassigned Class-Num (e.g,, 64 
< GlassTfvlum < 128 are unassigned) to signal whether 
or not a query to the PMD was perfoimed. Consistent 
vyrth the RSVPspecification» systems tiiat do not recog- 35 
nize the Object will quietly ignore it. However, systems 
that implement the inventive methodology disclosed 
herein will recognize the Object and act on its informa- 
tion. In other words, the disclosed methodology advan- 
tageously utilizes unused bfts in the RSVP protocol 40 
packet structure as a signaling mechsnism to commu- 
nicate information between sources and destinations. 

An example of the methodology defined above is 
presented in FIGs. 4d and 4e. In FIG. 4d, operation is 
identical to that of FIG. 4a upto and including Path mes- ^ 
sage (4). From there, destination (D) sends a query (5) 
to PMD 230. The query (5) contains the Information from 
the path message and the requested reseifvation of des- 
tination (D). Query (5) is processed by PMD 230 and a 
response (6) containing the required ATM traffic descrip^ so 
tors, QoS parameters and the various options is re- 
turned to destination (D). Once destination (D) has the 
results of the response (6) and cut-through is permitted 
(scenario when cut-through is not permitted is dis- 
cussed below), it sends an NHRP query (7) to its default 55 
NHS and receives a response (8) containing the ATM 
address of source (S). Destination (D) then sets up an 
ATM SVQ (9) directly to source (S) using the ATM QoS 



Information from response (6). Destination (D) then 
sends the RSVP Reservation Request message (TO) to 
source (S) over the established ATM SVG (9). Source 
(S) associates the RSVP Reservation: Request mes- 
sage (11) to the, RSVP Path message (1) by the use of 
the message ID fields in messages (1) and (11). 

In FIG. 4e, c^eration is identical to; that of FIG. 4d 
up to and including the query response (6) returned by 
Pf^D 230 to destriation (D). Once destination (D) has 
the results of the response (6) and cut-through is not 
permitted, destination (D) sends an RSVP Reservation 
Request message via Res (7), Res (8). Res (9) and Res 
(1 0) to source (S), using the stored path state inforhna- 
liqn in routers 120. 1 30 and 110 along the path fripm des- 
tination (D) to source (Sj. When source (S) receives the 
reservation (10), it deterrnines that a query to PMD 230 
was performed (communicated via the Object with 64 < 
Class-Num < 128 mechanism described above) and 
thatno query to PMD 230 by sources {S) ls heeded. Hbw- 
ever if source (S) delerminefs that a query to PMD 230 
was not pctrfonmied at destinatteh (D). it sends a query 
to PMD 23G. This is the case illustrated in FIG. 4a. 

Note that the methodology described in FIGs. 4a to 
4e applies to the IP unicast case (i.e., a single transmit- 
ter sending IP packets to a singje receiver); the meth- 
odology described in FIGs. 4d arid 4e (where the deisti- 
nation rather than the source queries the PMD) is also 
appropriate for the IP multicast case (i;e.i a single trans- 
rhitter sends IP piackets to'a group of receivers). In the 
multicast case, receivers decide whether or not to join 
a particular multicast; group. The transmitter may not 
even be aware of which receivers are receiving its Irans-^ 
mission. The receiver-driven nature of IP multicast 
therefore is weH accdmrtiodated by having receivers/ 
destinations query the PMD, as shown in FIGs. 4d and 
4e. When cut-through is. pernnitted, it is accomplished 
by a ATM level leaf-initiated join operation to either the 
source or an intermediate multicast server. Note further 
that, just as in the unicast case, in the multicast case 
the PMD may both resolve IP addresses to ATM ad- 
dresses and perform third party multipoint call setup 
functions on behalf on the querying entity. Furthermore. 
if the PMD performs such functions it rnay also imple- 
ment address screening, thereby providing an optional 
security function to multicast (and unicast) communica- 
tion. 

FIG, 5 details the contents of the policy mapping 
database (PMD) according to an embodiment of the in- 
vention. For each set of IP end-points, a customer en- 
ters whether or not to: 

(i) Enable cut-through with QoS mapping: When en- 
abiedi ATM cut-through to the destination is always 
attempted. There is a mapping of RSVP flow spec- 
ification parameters to ATM QoS parameters and 
traffic descriptors. Depending on the reservation 
style of RSVP, the mapping of RSVP flows to ATM. 
VGs may be 1 to 1 or many to 1 . 
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(ii) Enable cut-through without QoS mapping: When 
enabled^ ATM cut-through to the destination is al- 
ways attempted. The ATM SVC is always •best-ef- 
fort" with no QoS parameters or traffic diBscriptore 
being set The mapping typically is' many to 1 . s 
(ili) Disable cut-through, support hop-by-hop QpS 
mapping: When enabled, ATMcut-through is not at- 
tempted. Packets are forwarded hop-by-hop ac- 
cording to the Classcal IP routerrbased packet for- 
warding model. The mapping of RSVP flow specifi- io 
cation parametersto ATM QbS parameters and traf- 
fic descriptors takes place on a hpp-by-hop basis. 
Depending on the resen/alion style . qf RSVP, the. 
mapping of RSVP flows to the ATM SVC. The map- 
ping ot VCs maybe 1 to 1 or many to 1 . is 

(iv) NHRP Lookup Option 
If No, theri ignored^ 

If Yeis, then the PMD invokes ttie NHRP server 
(NHS)on behalf of the source iand returns the result 
of the query (i^e.. the ATM address of the^destina- 20 
tion) back to the source in the PMD response mes- 
sage. 

Third party setup by proxy signaling option 
If No, then ignored. 

If Yes, then the PMD, having invoked 25 
the NHRP server (NHS) on behalf of this source, al- 
so sets up an ATM connection between the source 
and destination using proxy signaling. If enabled, 
this sub-option assumes that both the source and 
destination have been provisioned to allow the PMD so 
to act as a proxy signaling agent for each. 

(v) Restrict cut-through option: 

If No, then ignored. 

If Yes. then the customer lists the set of desti- 
nation domain names, and IP addresses for which 35 
cut-through Is allowed for the given set of IP end- 
points. Address preffxes and domain names suffix- 
es are permitted. Cut-through is not attempted to 
destinations not in this list. 

(vi) Day/Time-of-day override: 40 
If No, then ignored. 

If Yes, then customer enters the days of the 
mortth and tihnes of the day. for which cut-through 
is not to be attempted. 

(vii) Multicast cut-through allowed: 

If No. then cut-through is not attempted for mul- 
ticast destinations (i.e.. if the destination address is 
a class D address). 

If Yes. then cut-through is permitted. The cus- 
tomer nn^y also list the set of class D addresses for ^ 
which cut-through is allowed, and the list of ATM 
end-points that may join a particular multicast 
group. 

(viii) Backup Option: 

If Yes, then ss 

(a) if current set of options require cut-through, 
and if cut-through fails, attempt a hop-by-hop 



setup. 

(b) .if current set of options require hop-by-hop 
and RSVP setup tails, attempt a cut-through. 

(ix) Use altjsnnate'ATM path when primary. ATM path 
falls: 

If No. then ignored: 

If Yes, then assuming that the destination is 
reachable from the source by 2 or more distinct ATM 
networks, and that PNNI routing between these net- 
works is not employed, the source may have 2 or 
more distinct ATM aiddresses for a given IP desti- 
nation; When a call siatup attempt to the first ATM 
addressfails, a second, third, etc.. attempt is made 
to the second, third, etc.. ATM address, until an at- 
tempt succeeds, or until there are no more alternate 
addresses. 

The above options may be grouped together to pro- 
vide different levels/categories of service to customers. 
For example, one (high) level of sen/ice might consist 
of enabling options (i), (vii), and (viii), while another level 
of service might consist of enabling options (ii), (rv), and 
(v). Further, the details of each option nnay change.^and 
additional options nrtay be added to the database without 
chariging the overall operation of the invention. 

An exemplary database query and response mes- 
isage contains the following parameters: 

Query: 

1 , The RSVP flow specification including both the 
traffic specificatibrts (amount and characteristics of 
bandwidth needed), service specific parameters (e.g.. 
packet delay, packet jitter, packet toss), and thei filter 
specrficatiorS identifying and .characterizing thje stream 
of packets in the packet flow. 

Response: 

1 . The contents of the query as described above. 

2. ATM related parameters 

Cut-through or ribt 
ATM traffic descriptors 
ATM QoS parameters 
Backup enabled (Yes/No) 
- Alternate ATM (Yes/No) 

If NHRP lookup is enabled, the ATM address 
con-esponding to the target IP address of the 
Query message 

If 3rd party setup Is enabled, theii the ATM Vir- 
tual Path^rtual channel identifiers (VPIA^CI) 
are used to reach the IP target 

Note that the query and response message content 
can be extended to allow override of some ol the 
provisioned entries in the PMD on a call-by-call ba- 
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sis. For example, one could request NHRP lookup 
tor some connections but not for others. The query 
messages are simply augmented by the addition of 
the yanpus options. It should also be appreciated 
th^t the system can alsp operate successfully even 
if the contents of the query message contains a sub- 
set (eg;, port number and destination address) of 
information. For example, if infonrnation pertaining 
only tbthe filter-specification was available, it is still 
possible to accomplish a mapping from destination 
address and port number to ATM QoS parameters. 
This enables the system to be used even when 
RSVP is not employed. 

While several embodiments of the invention are dis^ 
closed and described, it should be appreciated that var^ 
ibus modifications may be made without departing from 
the scope of the subjoined claims. 

Clafms 

1 . A method of operating a communications network, 
said hnethbd comprising the steps of: 

defining acoirtmunicatbns path (1. 2, 3, 4), be- 
Iwjaen at least one source (S) and at least one 
destination (D), for a user application; 
allocating network resources along said com- 
munications path; 

mapjaing Resource reSerVation Protocol 
(RSVP) parameters to Asynchronous Transfer 
Mode (ATM) parameters based on the addressr 
es of said souroa (S) and said destination (0); 
CHARAQTERIZED IN THAT 
said RSVP parameters are mapped to said 
ATM pararneters based on the resource re- 
quirements of at least one application being 
used on said communications network. 

2. The method as recited in claim 1 . wherein said map- 
ping step includes obtaining mapping information 
from a policy mapping database (PMD) (230). 



sending a query message (9) from said source 
(S) to a policy mapping database (PMD), 
whereini said query message includes RSVP in- 
formatidn acquired from the allocated netwoi^k 
5 resources, and 

retijrning a response message (10), based on 
said query message, from said PMD to said 
source, v^tierein said response message con- 
tains ATM parameters and RSVP parannelers. 

10 

5. The method as recited in claim 4, wherein sakJ map- 
ping step further comprises the steps of: 

generating, based on ^id response message 
1^ (1 0); a query request(1 1 ) from said source (S) 

to a Next Hop Resolution Protocol (NHRP) 
server to determine an ATM address for said 
destination (D),: 

transmitting ai-message (12) including an ATM 
20 address from said NHRP server to said source 

(3).and 

establishing, based on saki ATM address, an 
ATM switched virtual circuit (SVC) (|3) from 
said source (S) to said destination,(D). 

6. The method as recited claim 1 , wherein said map- 
ping step further comprises the steps of: 

transrnitting aquery message (10) from a polk:y 
50 nnapping datiabase (PMD) to a Ne^xt Hop Res- 

olution Protocol (NHRP) server on behalf of 
said source, and 

returning an. ATM address for said destination 
tosaiB polrcy nnapping database (PMD) (11). 

7. TTierriethpd as recited iri claim 1 , further comprising 
the step of establishing a switched virtual circuit 
(SVG) (13) based on said mapping step. 

40 8. The method as recited claim 1 , wherein said RSVP 
parameters ihclude flow specifications and wherein 
said ATM parameters include ATM Quality of Serv- 
ice (QdS) parameters and traffic descriptors. 



3. The method as recited in claim 1 . wherein said map- 4£ 
ping step irncludes the steps of: 

classifying packets in said communications 
network thereby creating classified packets, 
separating said classified packets based on 
said RSVP parameters, and 
correlating sakJ RSVP parameters with sard 
ATM parameters, based on a policy mapping 
database (PMD}. 

SS 

4. The method as recited claim 1 , wherein said map- 
ping step further comprises the steps of: 
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•ENABLE CUT-THROUGH WITH QOS MAPPING (YES/NO) 
•ENABLE CUT-THROUGH WITHOUT QOS HiAPPING (YES/NO) 
•HOP-BY-HOP QOS MAPPING (NO CUT-THROUGH) (YES/NO) 
•HHRP LOOKUP (YES/NO) 
•IF YES 

•3RD PARTY SETUP (YES/NO) 
•RESTRICT CUT-THROUGH (YES/NO) 
•IF YES 

•CUT-THROUGH ONLY FOR DESTINATION IN 
•DOMAIN 1, DOMAIN 2. ...DOMAIN M 
•IPNO 1. IPNET 2. ...IPNET N 
•DATEAOO (TIME OF DAY OVERRIDE) 
•NO CUT-THROUGH 
•fiWM T1-T2 
•FROM TN-TN-1 
•MULTICAST CUT-THROUGH ALLOWED? (YES/NO) 
•BACKUP OPTION (YES/NO) 

•USE ALTERNATE ATM PATH WHEN PRIMARY ATM PATH FAILS? (YES/NO) 
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